Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Significant performance enhancement for ASIDownloadCache's -clearCachedResponsesForStoragePolicy: #347

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

revetkn
Copy link

@revetkn revetkn commented Nov 19, 2012

Instead of walking each file and deleting it on the current thread, we move the cache directory to a uniquely-named directory in the temp directory and delete its contents on a background thread. For whatever reason the iOS filesystem can perform a rename very quickly but deletes - especially for larger files, e.g. images - can be very slow (orders of magnitude slower) on old devices like the iPad 1.

This approach should be safe even if the background deletion thread is unable to complete normally (e.g. the application is unexpected terminated during execution) because we can rely on the system to clean up for us eventually since we're operating on files in the temp directory.

ASIHTTPRequest is a great library and I have used it to build some high-traffic apps. Unfortunately I was really bitten by the cache-clearing performance on older devices. Users were unable to start up the app due to being killed by the iOS watchdog since the deletes took so long to execute. In our app, this call might have taken 20 seconds in the pathological case (!) on an iPad 1. Now it takes about 100ms.

Another way to address this would be to allow client code to specify ASIDownloadCache size/item limits, with some kind of LRU eviction. But this was a quicker, less invasive win for me.

…gePolicy:

Instead of walking each file and deleting it on the current thread, we move the cache directory to a uniquely-named directory in the temp directory and delete its contents on a background thread.  For whatever reason the iOS filesystem can perform a rename very quickly but deletes - especially for larger files, e.g. images - can be very slow (orders of magnitude slower) on old devices like the iPad 1.

This approach should be safe even if the background deletion thread is unable to complete normally (e.g. the application is unexpected terminated during execution) because we can rely on the system to clean up for us eventually since we're operating on files in the temp directory.

ASIHTTPRequest is a great library and I have used it to build some high-traffic apps.  Unfortunately I was really bitten by the cache-clearing performance on older devices.  Users were unable to start up the app due to being killed by the iOS watchdog since the deletes took so long to execute.  In our app, this call might have taken 20 seconds in the pathological case (!) on an iPad 1.  Now it takes about 100ms.

Another way to address this would be to allow client code to specify ASIDownloadCache size/item limits, with some kind of LRU eviction.  But this was a quicker, less invasive win for me.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant